User Authentication

With a few exceptions, a user cannot execute AccuRev commands unless he is authenticated as an AccuRev user. For authentication purposes, each registered AccuRev user has a username/password pair recorded in the registry. A user's password can be empty.

AccuRev automatically distinguishes two categories of users — those who have non-empty passwords and those whose passwords are empty. The keywords authuser and anyuser, respectively, are used by the ACL facility to designate these categories.

The "AccuRev Login" User-Authentication Scheme

Most AccuRev users are authenticated by explicitly logging in to the AccuRev Server. Using the GUI or the CLI, the user logs in by entering his username and password (possibly empty). This launches a user session, which is typically of limited duration (a few hours). When the session expires, the user must login again to continue using most AccuRev commands.

A successful login command creates an encrypted session file that records the user's AccuRev username and password, along with the IP address of the client machine. If an AccuRev client command can be executed only by an authorized user, the command automatically sends the information in the session file to the AccuRev Server process. Thus, the user does not need to repeatedly 'remind' the AccuRev Server who (and where) he is.

If a user is already logged in, and he successfully logs in again — as the same user or a different user — the existing session file is overwritten.

The "Custom" User-Authentication Scheme

AccuRev also supports script-based authentication of AccuRev users. For example, customers with an LDAP authentication scheme in place at their organization could configure a script to authenticate AccuRev users via LDAP. See AccuRev Security Overview in the AccuRev Admin Help for further details.

Locks on Streams

Each stream can have one or more locks on it. A lock prevents a certain set of users from using the stream to create new versions of elements. That is, it prevents execution of the Promote command — either promoting from the designated stream, or promoting to the designated stream, or promoting in either direction.

A lock can be absolute, applying to all users. Alternatively, you can specify that a lock applies to a particular AccuRev user, or to a particular AccuRev group. Conversely, you can specify that a lock applies to everyone except a particular AccuRev user, or to everyone except a particular AccuRev group.

Locks can also prevent reconfiguration of the contents of a stream with the include/exclude facility.

For more on locks, see The Locks Command.

Access Control List (ACL) Permissions

In addition to (or instead of) locks, each stream can have one or more permissions on it. Whereas a lock controls the ability to create new versions (through the Promote command), a permission is more general: in addition to controlling Promote, it controls the ability to read data from the stream, using such commands as Annotate, Diff, and Open. A permission also controls workspace-specific commands, such as Update and Populate.

Unlike locks, which always apply to individual streams, ACL permissions can be configured to apply to entire stream sub-hierarchies.

You can also create an ACL permission that applies to an entire depot. This provides a way of controlling access to all of a depot's file system data, in all streams. It also provides a way to control access to issues in a depot.

ACL Permissions and Time Considerations

ACL permissions apply to a stream regardless of any basis time on the stream. Similarly, ACL permissions can be placed on a snapshot, even though such permissions are necessarily created after the snapshot is created.

For more on ACL permissions, see the description of The Security/ACL Subtab.

Element ACLs (EACLs)

AccuRev also provides element-level ACLs, called "EACLs". An EACL is a set of permissions that controls the privileges that individual users or user groups have with respect to a particular element. EACLs can only be set by an AccuRev administrator using either the AccuRev GUI or the CLI.

The following table shows you where to find more information on working with EACLs in AccuRev.

If You Want To Learn...	See...
More about EACLs and the privileges you can associate with an element	The section Element-Level Security (EACLs) in the AccuRev Administrator’s Guide
How to set EACLs using the AccuRev GUI	Managing EACLs in the AccuRev GUI
How to set EACLs using the CLI	The section eacl in the AccuRev CLI User’s Guide

What Happens if You Are Denied Access?

GUI users can be denied access to elements or directories if an administrator has configured EACLs. Depending on the situation, you will either see an “Access Denied” error message, a (no such elem) status, or the element will be completely invisible to you, as if it does not exist:

For commands that take element names, if you are denied access to the namespace or content, you are denied access.
For commands that specify an eid, such as cat, the command will succeed if you are not denied access to that element. If you are denied access to the namespace of the element, the eid is displayed instead of the name.
For commands that display transactions, such as hist, if you are denied access to the element in the transaction, the transaction is displayed, but “Access Denied” is displayed for the path name.
For commands that take a transaction or issue, such as promote, if you are denied access to an element or elements in the trans or issue, the command succeeds and the elements are promoted, but the names are not displayed.
Commands that modify workspaces, such as update and pop, will succeed even if you are denied access to some of the elements, but those elements will not be brought down to the workspace. The exception to this is if you specify the element name, such as with pop or co. In this case the command will fail as if the element doesn’t exist.
For commands such as stat, dirstruct, and files, where you specify an option or nothing instead of an element name, if you are denied access to either the namespace or content, nothing will be displayed for that element. For example, stat –d displays all the elements in the default group of the stream. If you are denied access to an element in the default group, it will not be displayed.
When you are denied access to an element, AccuRev behaves as if the element does not exist. Depending on the specific circumstances, AccuRev will either:
- Filter out the denied element altogether, so that there is no indication that it even exists. this is the default behavior.
- Return an Access Denied status. This occurs when the only element in a display is denied, and a blank display would be confusing (for example, if the Show Active Files display in the StreamBrowser contains only denied elements).
- Display a (no such element) status. If your access to an element or namespace changes during a session, and you are now denied access to something that was already displayed, that element or folder will appear with the (no such element) status.
If you have multiple Access Denied elements in the default group, the GUI will combine these into a single Access Denied row.

For information about EACLs, see AccuRev Security Overview in the AccuRev Administrator’s Guide, and the command summary for eacl in the AccuRev CLI User’s Guide.

Restricting Access to Commands using Triggers

By default, any registered AccuRev user can execute any AccuRev command. Many organizations wish to restrict users' access to certain commands, such as the ability to maintain users, groups, and passwords, the ability to lock streams and create ACL permissions, and so on. Triggers provide a flexible mechanism for implementing command-based security.

Many AccuRev commands can be configured to "fire a trigger". This causes a user-defined script to execute ...

either before the command executes (pre-operation trigger), or afterward (post-operation trigger)
either on the client machine, or on the server machine

A pre-operation trigger can affect the execution of the command or cancel it altogether. Typically, a security-related trigger checks the identity of the user invoking the command, then decides whether or not to allow the command to proceed.

Some triggers are configured on a per-depot basis, using the mktrig command. These triggers monitor individual commands (add, keep, and promote). Three are pre-operation triggers that fire on the client machine; one is a post-operation trigger that fires on the server machine.

Other triggers are configured, on a per-depot or whole-repository basis, by placing a script in a well-known location on the server machine. These triggers monitor groups of commands, rather than individual commands.

For more on triggers, see The Triggers Tab, and also AccuRev Triggers of the AccuRev Administrator’s Guide.